(Reprinted with light editing from my Wednesday July 14, 2004 entry — a New Year's Eve tribute/thoughtpiece.)
"2038 is The End Of The World As We Know It." Technically it is the end of an epoch, or perhaps The Epoch to us programmers. The Epoch is the range of dates starting at January 1, 1970 00:00:00 GMT and ending at January 19, 2038 03:14:07 GMT, used by Perl/Unix/Linux/*BSD's time(), Java's Date class, and C/C++'s time() (and I suspect others). This past January 9th (2004-01-09) was the half-way point of The Epoch's usability. (Microsoft Windows and MS-DOS's epochs end in 2048 because they started in 1980, but they use the same 32-bit date storage as The Epoch.)
So why does this matter to me, you ask? Because if you write code that reads or writes dates, that code will fail in less than 34 years. (2007-12-28: less than 30 years now.)
34 years is a long time, you may say. I used to think so, too. Then one day I realized that some regular expression code I wrote more than 20 years ago was still shipping in a product that showed no signs of being near the end of its lifecycle.
Code for handling dates, whether for reading, writing, or calculating dates, will start failing when it is asked to handle dates beyond the January 19, 2038 03:14:07 GMT lifespan of The Epoch. This doesn't affect just those of us who work on Web applications, although I will be interested to see how weblogs and online newspapers handle 2038 — I would hate to lose the access to the contributions of my fellow use.perl.org bloggers, Jerry Pournelle, or Dave Winer over a date error.
January 19, 2008 03:14:08 GMT is important, as you cannot add 30 years to that time without exceeding the limits of The Epoch, thereby affecting some mortgage calculations (30-year mortgages are common here in the States). (Long-term bond maturation calculations (among others) will also be affected by the end of The Epoch.) As a practical matter, 30-year mortgage failures from The Epoch should start occurring around February 20, 2008, as you can't use Epoch dates to calculate the last mortgage payment date (if I have performed the calculations correctly). 2008 is only four years (days!) away. (There have been 50-year mortgages originated in Japan within the past 15 years — but there may not be any programs using Epoch dates that had to handle those mortgages.)
January 19, 2018 03:14:08 GMT will also be important here in the States at least, as you cannot add 20 years to that time without exceeding the limits of The Epoch, thereby affecting 20-year mortgage calculations. 2018 is only 14 years away (2007-12-28: 10 years + 4 days) — which should be well within the date range that software engineers (Perl or otherwise) should be considering when creating or updating date-handling code today.
"But I Feel Fine" (thereby completing the R.E.M. reference), as my new code uses non-Epoch dates. New Perl code will use DateTime, and my latest Java code already uses the Java GregorianCalendar class. (I still need to research date alternatives for C++ and C.) I confess to feeling a little like Ed Yourdon, who (if I remember correctly) started warning about Y2K problems in the early 1990s, long before the problem really caught the attention of software engineers and IT managers.
If your code (old or new) handles dates, you need to be concerned about 2038 ITEOTWAWKI ("2038 Is The End Of The World As We Know It"). Perl now has DateTime, which looks like it will work well for most date applications. Readers using other languages will need to do some research (except for Java GregorianCalendar, as noted above). Happy date-handling!
Re:The real challenge is file formats
pudge on 2008-01-10T01:23:35
My bet is that when 2038 gets closer people will just look at the problem and say, "Why don't we just change from using a signed int to using an unsigned int?" Thereby pushing the problem close to 40 years farther out without having to reformat every filesystem out there.It's about 68 years. Better than 40! That solution is better for filesystems than programs, of course, since some programs need to go prior to 1970, so taking away the signed is bad, but you usually won't need files that existed before 1970.
